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PLANNING TO USE PUBLIC PACKET NETWORKS 


Last month we discussed how the new ‘personal’ micro comput- 
ers will probably accelerate the movement to distributed systems. 
Many will be used both as stand-alone processors as well as intelli- 
gent terminals for network use. Hence, user organizations will be 
faced with a continually growing demand for data communication 
network services, to serve the micros, the minis, and the other levels 
of distributed processing. Further, the variety of brands of comput- 
ers to be tied to the network probably will increase. How best can 
the needed communication services be provided? Most large users 
are making extensive use of leased circuits for their data communi- 
cations. But public packet switched networks, about which we have 
been writing for several years, are now becoming viable options. 
This is the first of four reports on aspects of distributed systems 
and the automated office, and how network services will impact 
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them. We think these subjects deserve your serious attention. 


i ere et Gaz de France (EDF-GDF) 
are two public companies that control electricity 
production and distribution as well as gas distri- 
bution, providing power to over 20 million 
homes and employing 120,000 people. As one 
would expect, EDF-GDF has been making exten- 
sive use of computers for engineering, scientific, 
and business applications. But this use of com- 
puters is now undergoing a rather interesting 
change. 

At the present time, the company has comput- 
ers located in seven cities in France, plus termi- 
nals in hundreds of other locations. The com- 
puter centers are tied together by a leased line 
network. But the data communication services 
are closely tied to the applications yoo serve; a 


change in one generally will cause a change in 
the other. 


The people at EDF-GDF are currently gaining 
experience with six distributed processors. Even- 
tually, this may lead to about one hundred 
processors serving thousands of terminals. But to 
operate in such an environment, they see that a 
very different kind of data communication service 
is needed. The current dependence between the 
data communications and the application pro- 
grams cannot be tolerated. Each application sys- 
tem cannot have its own special data communi- 
cations service. 

What EDF-GDF seeks is a data communication 
service with the following characteristics. First, it 
should serve all users and all traffic types with a 
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common network. Second, it should be transpar- 
ent to all users (in the same way that the tele- 
phone network is transparent for voice telephone 
calls, acting almost as if the speakers are talking 
face to face). Third, the service should be inde- 
pendent of the application programs, the com- 
puter hardware, and the systems software that 
are used. Fourth, the service should be designed 
so that any terminal can access any relevant ap- 
plication. 


Further, any node of the network must be able 
to handle a mixture of traffic in a common man- 
ner, say the people at EDF-GDF. The types of 
traffic that must be handled include bulk (file) 
transfer, batch transfer, and interactive traffic. 
Moreover, the traffic must be handled on a pri- 
ority basis, with interactive messages receiving 
the highest priority. Real-time process control 
applications have been excluded from this project 
and will continue to use their own dedicated 
communication services. 


The general approach 


The company has selected TRANSPAC, a 
packet switched network being installed by the 
French PTT (post, telephone, and telegraph), as 
the basis of their network. TRANSPAC has been 
under development since 1971 and will begin 
commercial operation later this year. We will 
have more to say about ‘TRANSPAC shortly. 

The company has designed ‘stations’ to inter- 
face with the network, for providing a common 
access to the network for all its users. In fact, if a 
terminal must access another terminal at the 
same location, they communicate through the 
station to which both are attached, so that com- 
mon procedures are used throughout. 


Some stations will handle mainly business 
traffic (interactive and bulk transfers), others 
will handle mainly scientific traffic (batch trans- 
fers), and some will handle a mixture. Hence, 
stations must be able to handle such mixtures of 
traffic. 

The stations in turn will interface with the 
X.25 synchronous protocol (to be discussed be- 
low) used on the TRANSPAC network. So a sta- 
tion must be able to handle signals of teleprinter 
and display terminals as well as X.25 synchro- 
nous transmissions. 


The stations will be using several levels of 
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EDF-developed protocols for handling the traf- 
fic. These include: 


Network access procedures. The MART (Mod- 
ule Access Reseau TRANSPAC) module provides 
communication link management, matching be- 
tween links and virtual calls, network call con- 
trol, packet protocol, virtual call set-up and dis- 
connect, and block fragmentation and re-assem- 
bly. (We will be discussing some of these con- 
cepts later in this report, in case they are not fa- 
miliar to your.) 


An international standard for packet networks 
has been established, called X.25, which includes 
the ‘virtual call’ discipline for these networks. 
This discipline uses the concept of a defined 
routing, from source node to destination node, 
for all packets transmitted. In concept, it is very 
similar to a telephone circuit; it is a virtual cir- 
cuit from source to destination. The virtual cir- 
cuit may be set up on a permanent basis (like a 
‘hot line’ telephone) or on a temporary basis 
(like a dialed telephone call). 


A communication link uses a virtual circuit, so 
that a virtual circuit may handle more than one 
communication link. For example, if there are 
several terminals at one location that are com- 
municating with a host processor at another lo- 
cation, each terminal would be using its own 
communication link, but all of these links could 
be handled by the same virtual circuit, in the 
same way that terminals share a common tele- 
phone circuit today. 


So the company’s network access protocol sets 
up virtual calls and assigns communication links 
to the virtual calls. 


Block handling protocol. ‘The next higher level 
of protocol that the company has developed deals 
mainly with flow control. First, it is responsible 
for establishing and disconnecting communica- 
tion links. Once a link has been set up, this pro- 
tocol module (which they call MCC—Module of 
Communication between Correspondents) checks 
to see that all blocks in a message have been sent 
or received. Blocks may be up to 2,000 charac- 
ters in length. ‘This MCC module handles block 
acknowledgement and error recovery. 


Terminal protocols. ‘Vhe station is designed to 
be able to use a Virtual Terminal Protocol, a 


standard procedure for serving classes of termi- 
nals, for interactive, batch, or bulk transfers. In- 
terface hardware and/or software may be 
needed, of course, to convert any particular ter- 
minal type to agree with the virtual terminal 
protocol. But a new terminal type may be added 
to the network generally by just providing this 
interface. At first, however, EDF-GDF will not 
provide users with such a protocol. Instead, all 
CRT terminals will be intelligent and will be 
programmed to interface with the processors. 


Developing the concepts 


The company has been conducting research 
and development on these network concepts since 
1974, as described in Reference 1. When the 
TRANSPAC network becomes operational a few 
months from now, EDF-GDF will begin putting 
them into pilot operation. 

The first step in their project, completed in 
early 1975, was to represent two stations and a 
computer center on an IBM 370/145 running 
under VM 370. They began their first simulations 
of network operations in this manner. 

The second step, conducted during 1975, was 
to take the terminal station software out of the 
370 and put it into a Cii MITRA 15 mini com- 
puter. At this point, there still was no packet 
network involved but communications between 
stations was simulated and different protocol re- 
quirements were investigated. 

The third step, which was completed in early 
1977, involved taking the host station software 
out of the 370 and putting it into a front-end 
processor (a Systems Engineering Laboratories 
SEL 86). Also, they began using the PTT’s experi- 
mental packet network, RCP, operating under a 
virtual circuit protocol. 

The fourth step, which they expect to com- 
plete late this year, is to begin pilot operation 
with the TRANSPAC network, serving six outly- 
ing computer centers and terminals at some loca- 
tions. The bulk transfer protocol and the batch 
transfer protocol programs were completed ear- 
lier this year, and they hope to have the interac- 
tive protocol completed by November. With all 
of the development work that has already been 
done, they hope and expect that this step will go 
relatively smoothly. They will then be ready to 
begin productive use of the network and to ex- 
pand the number of processor and terminal sites. 
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Eventually, EDF-GDF foresees a_ processing 
center in each of France’s geographic depart- 
ments, plus national centers at Clamart, near 
Paris, and Issy-les-Moulineaux. Their network 
control center will also be located at Issy-les- 
Moulineaux. While they expect some center to 
center data flow, the main flows will be from 
terminals to centers and then from centers to the 
national centers. 

EDF-GDF plans to use TRANSPAC for a large 
part of the data communications. However, in 
some instances, leased lines will be used where 
they are less expensive—for short distances and 
heavy traffic. But the same block handling proto- 
col will be used in either case, thus providing 
users with a common communication service. 
EDF-GDF feels that TRANSPAC can provide, in 
addition to some standardization, an economical 
and evolutionary means for communicating be- 
tween computers and terminals spread all over 
the country. 


Transpac 


As mentioned earlier, the French PTT became 
interested in packet network technology in 1970 
and in 1971 decided to build an experimental 
packet network. This RCP network was put into 
operation in January 1975 with three nodes, at 
Paris, Rennes, and Lyon. A second Paris node 
was later added to the network, and last year a 
fifth node, with an X.25 interface, was con- 
nected. The RCP network is considered semi-ex- 
perimental; it is in operational use, with a vari- 
ety of host computers, and eight hours per day of 
availability is guaranteed. It can be accessed by 
leased lines to the nodes, or by dial-in to the 
nodes from the Telex network or the telephone 
network. 

Last year, RCP was used in an interesting 
demonstration, given in conjunction with the 
IFIP Congress in Toronto in August and the SI- 
COB Conference and Exhibition in Paris in Sep- 
tember. A trans-Atlantic connection was made 
with the Canadian Datapac network, using the 
X.25 protocol. A variety of computer types and 
terminals in France were put into communica- 
tion with a variety of computer types and termi- 
nals in Canada, as a convincing demonstration of 
the practicality of public packet switched net- 
works. 

In addition to this work of the PTT, research 


in packet networks was also going on at IRIA, on 
an experimental packet network developed under 
Project CYCLADES. 

Based on their own early work and that of 
IRIA, the French PTT decided in 1973 to go 
ahead with a public packet network, which they 
named TRANSPAC. The goal that was set was to 
have this network in operation with 12 nodes in 
1978. Now, five years later, the network is slated 
to begin operation this fall. 

One of the critical decisions facing the net- 
work designers early-on was: should the network 
use the virtual call discipline or the datagram 
discipline? We described the virtual call disci- 
pline above. In the datagram discipline, each 
packet contains the complete address of its desti- 
nation and may follow any route through the 
network, depending upon instantaneous traffic 
loads. Thus, two sequential packets of a block 
may follow very different routes through the net- 
work and the second packet may, in fact, arrive 
ahead of the first packet. Software is thus needed 
to put the packets back into their normal order 
and to make sure that all have been received. 

There has been, and there still is, considerable 
debate on the pros and cons of these two disci- 
plines. Suffice it to say that the French PTT fa- 
vored the virtual call discipline and found that 
all other PTTs that were considering public 
packet networks felt the same way. About this 
time, the virtual call discipline was proposed as 
an international standard for packet networks, as 
a part of X.25, so the decision became easy. 
TRANSPAC would use the virtual call discipline. 

TRANSPAC may be accessed in several differ- 
ent ways and in a number of different speeds. It 
may be accessed from the public Telex network 
at a speed of 50 bits per second (bps). It may be 
accessed by two-wire leased lines or from the 
public telephone network at speeds of.110, 150, 
200, or 300 bps, asynchronous operation. With 
four-wire access, speeds of 600 or 1200 bps 
asynchronous or 2.4, 4.8, 9.6, 19.2, or 48 kbps 
synchronous can be used. 

Packets may be up to 32 bytes (which they 
call ‘octets‘) or 128 bytes in length; both maxi- 
mum lengths are available. It is up to user soft- 
ware to fragment blocks into packets and reas- 
semble the blocks at the destination. 

Charges for the use of TRANSPAC within 
France are completely distance independent. 
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Charges are based on the method and speed of 
access, plus a connection charge, plus a packet 
volume charge. 


The people at TRANSPAC foresee their net- 
work connecting to other public packet networks 
in the not distant future. These include networks 
in Belgium, Netherlands, Spain, U.K., Canada, 
U.S., and Japan. For multi national computer 
users, it means that high quality packet commu- 
nications will become available in numerous in- 
dustrialized countries in the near future. 


Hughes Aircraft Company 


Hughes Aircraft Company, with headquarters 
in Culver City, California, is owned by the 
Howard Hughes Medical Institute, a non-profit 
medical research foundation. HAC is a large 
manufacturer of electronic and industrial pro- 
ducts and employs some 35,000 people. Plants 
and research centers are located in Southern 
California, between Santa Barbara on the north 
and Carlsbad in the south (about 200 miles). In 
addition, the company has a plant in Tucson, 
Arizona. HAC since its inception has been very 
heavily involved in the development and manu- 
facture of sophisticated electronics equipment, 
such as airborne fire-control radar, air defense 
control systems, the first lunar landers, and the 
development of synchronous communications sat- 
ellites. 


Because of the high technology involved in its 
products, HAC is very engineering oriented. And 
because computing is an important support serv- 
ice for engineering, the engineers have had a big 
voice in the selection of computing equipment to 
meet their specific needs. The result has been 
that a variety of computers are in use, including 
IBM 370s, Amdahl 470s, Honeywell 66/70, DEC 
PDP-10 and PDP-11, Hewlett Packard HP1000 and 
3000, Burroughs B1726, and Xerox Sigma 9. In 
all, 20 computers are in use in 13 separate in- 
stallations, not including an increasing number 
of mini computer installations. 


The company’s main computer center, consist- 
ing of two Amdahl 470s and a Honeywell 66/ 
70, is in Fullerton, California, just south of Los 
Angeles. As might be expected with the several 
computer centers, data communications has con- 
tinued to grow at a fast rate. In particular, more 
and more lines have been requested into the 


Fullerton center. In most cases, the data commu- 
nications services are closely tied to the applica- 
tions. Even though some of the leased lines have 
some available capacity, other applications may 
not be able to use those same lines because of in- 
compatible disciplines. 


So, in mid-1977, the corporate director of 
computing and data processing initiated a project 
to study HAC’s future needs for data communi- 
cations. He wanted a study made of the different 
options available to the company and the pros 
and cons of each option. 


One of the requirements was, of course, that 
the data communications service be able to serve 
a variety of computer types. Corporate manage- 
ment was unlikely to force one standard com- 
puter type on the various users. 


Another requirement was that the communi- 
cations network be able to handle growth both in 
volume and in number of applications. In order 
to handle this growth economically, it was recog- 
nized that the network should be application in- 
dependent, serving all applications on a common 
basis. 


One of the options available to HAC was to 
build a private data communications network, 
using leased lines, and based on one or more of 
the new network architectures offered by the 
computer manufacturers. These architectures in- 
clude IBM’s SNA and DEC’s DECNET. But 
analysis showed that this approach would have 
difficulty in meeting. HAC’s needs. Each archi- 
tecture favored the manufacturer that developed 
it; interfaces for the other makes of computers 
are not provided, in general. Further, the archi- 
tectures are not compatible with each other; it 
would be difficult to try to inter-connect two or 
more of these networks. 


Another option available to HAC was to ob- 
tain flexible front end processors, such as those 
made by COMTEN and CCI. While these front 
end processors tend to favor IBM equipment, 
they can be interfaced with other brands of com- 
puters and with a variety of terminal types. This 
was a viable alternative, as far as HAC was con- 
cerned. 

A third option was to use a public network 
such a Telenet or Tymnet. By the nature of their 
business, these networks must interface with a 
variety of computer types and terminal types. 
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This also was considered to be a viable alterna- 
tive. 

A fourth option that was considered is really a 
variation of the third one. In this case, packet 
switching equipment and software would be pur- 
chased or leased from the public packet carrier 
and put on HAC premises. For the bulk of the 
data communications, lines leased by HAC 
would inter-connect the nodes of its private net- 
work. But where distances were long and traffic 
volumes not great (as in the case of communica- 
tions with numerous district offices around the 
country), then the public packet network could 
be used. Further, the public packet network 
could be used for backup and for handling peak 
load conditions. | 

After some months of study, the project recom- 
mended to the director of computing and data 
processing that the fourth option be selected by 
having Telenet furnish necessary hardware and 
software for a Hughes private packet network. A 
phased schedule for Telenet implementation, 
with appropriate benchmarks, is being estab- 
lished for evaluation of service. 

Some of the Telenet features that appeal to 
HAC are the following. Telenet is well qualified 
in serving large numbers of all brands of com- 
puters and terminals, and has been subjected to 
the day-to-day grind of solving problems that 
only an operating communications carrier has 
experienced. Because of its own needs, Telenet 
has developed and is using software to gather 
and process statistics on line utilization and error 
rates, for dynamic network management. They 
have the software to gather actual usage data for 
the equitable distribution of data communica- 
tions costs to users. The private packet network 
provided by Telenet will be able to set up all 
communications calls within the private network 
and will not be dependent upon the public net- 
work. 

Interestingly, the packet technology appears to 
make the most efficient use of the leased lines for 
the Hughes network, even though the route 
mileages of this network are low due to its con- 
centration in Southern California. 

Perhaps most importantly, given Hughes’ suc- 
cessful use of many makes of computers and ter- 
minals, the Telenet approach provides the com- 
pany with a private network that will support 
just about any front-end processor or terminal 


that Hughes organizations desire to use. New 
computers, front-end processors, and terminals— 
and even new nodes—can be added without a 
traumatic redesign of the network. 


Looking not too far down the road, the people 
at HAC can see the day when engineers and 
others within the company will want to use their 
own micro computers for routine smaller func- 
tions. And these people will probably want to be 
able to tie into the company network when the 
need arises, so as to be able to access services on 
the larger computers. “That is when we will re- 
ally be thankful we have an application indepen- 
dent communications utility,” they said. 


Telenet 


Telenet Communications Corporation, with 
headquarters in Washington, D. C., was the first 
U.S. packet switched common carrier. Its tariffs 
became effective in August 1975. Telenet was 
also the first U.S. packet network to implement 
the X.25 service. Its nationwide network now 
provides communications for over 190 U.S. data 
centers whose users are spread throughout North 
America and in Western Europe, Puerto Rico, 
and Hawaii. 


As indicated, Telenet is a public packet car- 
rier. This means that it must serve users in other 
countries by way of public packet switched serv- 
ices offered by telecommunications agencies in 
those other countries. Service to Canada is pro- 
vided by inter-connecting the Telenet network to 
the Trans-Canada Telephone Service’s Datapac 
network. The U.K. Post Office has purchased 
Telenet equipment in order to provide the 
needed packet switching interfaces (as has the 
Hawaiian Telephone Company). In Mexico, 
Telenet interfaces with ‘Teleinformatica de Mex- 
ico. And for crossing the oceans, Telenet has ar- 
rangements with three international record carri- 
ers, RCA Global Communications, ITT World 
Communications, and Western Union Interna- 
tional. 


The Telenet public network is expanding rap- 
idly, in the number of U.S. cities served, in the 
number of other countries served, and in the 
number of user organizations served. So the fig- 
ures given above will quickly become obsolete. 
For instance, it possibly will not be long before 
Telenet users in the U.S. communicate regularly 
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with terminals connected to public packet net- 
works in France, Italy, Spain, Belgium, Nether- 
lands, Hong Kong, and Japan. And with public 
packet networks in operation in other countries, 
computer to computer communications can take 
place, not just terminal to computer. 

In addition to the public packet network, 
Telenet has other offerings. It can sell or lease its 
hardware and software, for use as on-site nodes 
for the public network or for private network 
use, as HAC is doing. It can provide network 
management or network maintenance for private 
networks that use Telenet equipment. It offers a 
‘Hotline’ packet service, which is the functional 
equivalent of a point to point leased line. When 
a terminal is turned on, the Hotline service auto- 
matically establishes the virtual circuit to the 
pre-established destination. And Telenet is now 
offering ‘TELEMAIL, a terminal to terminal mes- 
sage service. 


Terminal access and speeds. One way by 
which terminals can access the Telenet network 
is by way of the nearest Telenet central office. 
Three options are available for performing this: 
by dial-in over the telephone network to a public 
network port (including the use of In-waATS), by 
dial-in over the telephone network to a private 
port, and by a leased line to a private port. Pri- 
vate ports are assigned to specific customers and 
are not shared among customers as are the pub- 
lic ports. 

Another way by which terminals can access 
the Telenet network is by having a Telenet 
Processor (TP) on the customer’s site. In effect, 
this processor becomes a node of the network. 
Several TP models are available, the smallest of 
which handles seven asynchronous terminals, 
and the largest handles up to 480 asynchronous 
and synchronous terminals. The terminals may 
operate at 50 to 300 bps or 1200 bps, under a 
variety of protocols, including X.25. The TPs are 
also used to interface customer computers to the 
public network. 

The terminal protocols that Telenet presently 
provides include their own Teletype-compatible 
asynchronous protocol, an IBM 3270 and 2780 
bi-syne protocol (in private Telenet-furnished 
systems), and the X.25 synchronous protocol. The 
X.25 interface may require special hardware and 
software for controlling the terminals and does 


require an X.25 software interface in the host 
computer. 

The most commonly used speeds are: 50 to 
300 bps fixed speed asynchronous operation; 110 
to 300 bps adaptive speed asynchronous ppera- 
tion; and 1200 bps asynchronous. The X.25 syn- 
chronous operation is expected to grow rapidly; 
Telenet will be offering this protocol throughout 
the U.S. by the end of this year. 


Tariffs. For U.S. domestic use, tariffs are dis- 
tance independent; the charge for transmitting 
across a city is the same as transmitting across 
the country. Charges are based on the access 
speed used and the number of packets transmit- 
ted. At the 300 bps speed, the charges average 
out to about $3.50 to $4.00 per hour. Signifi- 
cantly, at 1200 bps, the rates are the same for 
public dial-in access. (To these charges must be 
added the cost of modems and telephone service.) 

For international use, distance-dependent 
charges do enter the picture. At the least, the 
charges vary by country. In some cases, the serv- 
ices of international record carriers are used, the 
latter generally offering lower end-to-end rates 
for the user. Finally, one or more supra-national 
packet networks, such as EURONET, may be 
linked to Telenet in the future, extending packet 
service to another set of Western European 
countries. 

For more information about Telenet services, 
see Reference 3. 


Planning for data communications 


It is generally only the larger organizations 
that have one or more people assigned to the 
function of planning for the overall use of tele- 
communications services. These services include 
the telephone, Telex or TWX, facsimile, and 
data. Even when one or more persons are as- 
signed to this function, they may depend heavily 
upon help from the telecommunications agencies. 
In only a small percentage of user organizations, 
we gather, are these people actually doing the 
whole planning function themselves. 

Our discussion is this report is concerned with 
planning for data communications, and in partic- 
ular, considering the use of public packet net- 
works in this planning. It should be noted that, 
in most organizations, data communications 
charges represent only a small percentage (say, 
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5% or so) of the total telecommunications charges 
paid by the organizations. Typically, voice tele- 
phone charges far outweigh data communications 
charges. 


But most medium and larger size organiza- 
tions are finding their data communications 
charges growing. Further, the data communica- 
tions services they are using may well be inflex- 
ible and closely tied to the specific applications 
for which they were installed. The networks 
have evolved; they have not been planned. 
Leased lines are used where the traffic volume is 
high; dial-up services are used for the lower 
trafic links. Different terminal protocols are 
used for different applications. It may not be 
possible to share communication circuits among 
several applications because of the differences in 
protocols and speeds. These are only some of the 
difficulties that are being encountered but they 
give an idea of the problems. 


Thus, even though data communications rep- 
resents a small percentage of overall telecommu- 
nications expenses, we think it deserves more at- 
tention than it has been receiving. Now is a good 
time for users to think in terms of a ‘data com- 
munications utility’ to serve a/l applications. 


A typical approach. If an organization begins 
to think in terms of a ‘data communications util- 
ity’ for serving all applications, typically the first 
thing that comes to mind is a private network, 
because of the problems of using many switched 
telephone networks at other than the lowest 
speeds. This approach has been encouraged by 
the computer manufacturers, because they can 
more easily control the computer equipment con- 
nected to a private network. 


If the organization has standardized on one or 
a very few brands of equipment—say, one brand 
of CPU and associated equipment, plus two or 
three brands of terminals—this approach can 
make a lot of sense. ‘The economics can be even 
more appealing if most of the locations are 
within a small geographic area, so that leased 
line charges will be relatively low. 


But if the organization has—or foresees hav- 
ing—a variety of equipment brands, then this 
approach begins to be less attractive. ‘This ap- 
proach tends to favor the manufacturer who sup- 
plies-the network components; IBM7’s SNA favors 


IBM equipment, for instance. The other manu- 
facturers favor their own equipment but gener- 
ally will also support some IBM equipment and 
common asynchronous terminals. It would be 
rather difficult to connect, say, IBM, Univac, 
Honeywell, and Burroughs computers on the 
same private network. As mini and micro com- 
puters enter the picture, the difficulties of trying 
to serve all of them will increase. | 


Another option: public networks. Public data 
networks now offer a viable alternative to private 
networks. These public data networks are those 
installed by the telecommunication agencies and 
providing swztched data services. There are two 
forms of switching being used: circuit switching 
and packet switching. (We have discussed this 
general subject in our February 1975 and July 
1976 issues.) 


Circuit switching. For speeds up to 9600 bps, 
users can use at least some of the public tele- 
phone switched networks in the world. At 300 
bps, service seems to be reasonably reliable on 
the networks in most industrialized countries, we 
are told. As transmission speed increases toward 
9600 bps, error rates increase significantly on all 
telephone networks—and some become unusable 
well below this speed. For practical purposes, 
9600 bps represents an upper limit on speed on 
the swztched telephone networks. 


Some telecommunications agencies have de- 
cided to provide reliable switched data services 
over a wide range of speeds by building special 
circuit switched networks. The Bell System of- 
fers a high-speed Dataphone Switched Digital 
Service, as well as a 50 kbps switched service to 
a few U.S. cities. The West German EDF data 
network is a circuit switched service. And the 
Nordic Data Network, installed by the PTTs of 
Denmark, Norway, and Sweden, is a circuit 
switched service. 


The point to emphasize is that, as transmis- 
sion speeds exceed 1200 bps, the existing tele- 
phone switched voice networks prove more and 
more troublesome. In order to provide switched 
service at speeds over 9600 bps (and even lower, 
in many cases) special switched digital networks 
must be built. 


Packet switching. Packet switching technology 
can provide a wide range of transmission speeds 
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at very low error rates over existing analog tele- 
phone facilities. The reason is that the packet 
network uses leased wide band transmission 
trunks (say, 56 kbps or higher) where noise 
problems are less. It avoids the telephone switch- 
ing system and instead does all of the routing 
switching by computer technology. At each node, 
the error detection code of each packet is 
checked; if an error is detected, retransmission of 
the packet is requested. When digital data serv- 
ices ave available, such as the Bell System’s DDS 
or Canada’s Data Route, the packet network can 
make use of those services, reducing the retrans- 
mission problem. 


Because transmissions are made in standard 
formats, a variety of terminal types and com- 
puter types can be interfaced to a packet network 
by converting their outputs into the standard 
packet format. And because high speed trunks 
are used, the delay time for the transmission of a 
packet is small; most of the delay is the switching 
time in the nodes. For reasons such as these, 
many of the world’s telecommunication agencies 
have seen packet switching as a way to provide 
high quality public data networks in relatively 
short time and at relatively low capital invest- 
ments. 


The emerging public networks 


While our main discussion in this report will 
deal with public packet networks, we will set the 
stage by describing some work that compares cir- 
cuit switching versus packet switching for data 
networks. We will then get into a brief discus- 
sion of the types of protocols involved, including 
the X.25 protocol previously referred to. 


Circuit vs. packet switching 


Kirstein (Reference 4) gives a good overview 
of the newly emerging public data networks, and 
a comparison of the existing tariffs for data com- 
munications. Using the existing telephone facili- 
ties (either dial-up or leased lines) for data com- 
munications, the following are the typical oper- 
ating speeds, he says. For asynchronous opera- 
tion, the most common speeds are 200 bps full 
duplex and 600 bps half duplex, with 48 kbps 
half duplex also being available. For synchro- 
nous operation, the most common speeds are 2.4, 
4.8, and 48 kbps half duplex, he says. But these 


are only the most common offerings; the actual of- 
ferings of any particular PTT can be quite dif- 
ferent. 

Now compare these common speeds and line 
disciplines with the recommendations of CCITT, 
the international telecommunications standards 
committee. CCITT recommends 200 bps asyn- 
chronous and 600 bps, 2.4, 9.6, and 48 kbps syn- 
chronous operation, says Kirstein. 

How does one get international swetched data 
communications services using the switched tele- 
phone network? It is a problem, as these figures 
indicate. Most users of international services 
thus resort to leased line private networks. There 
are also problems of wide differences in tariffs. 
Kirstein points this out vividly in his paper. Da- 
vid Butler, quoted in Reference 5, points out fur- 
ther that these tariffs are constantly changing, 
and so frequently that his firm had to give up 
publishing a report on European communica- 
tions tariffs. 

Rosner (Reference 4a) has reported on an 
analysis he made of circuit switching versus 
packet switching on a large hypothetical net- 
work. One half of the traffic on the network was 
assumed to be short messages, where a rapid re- 
sponse was desired. The other half of the traffic 
was long messages. Earlier studies of circuit 
switching versus packet switching, he said, had 
always involved a single type of traffic. 

Rosner’s study led him to conclude that 
“clearly...a common user data network can be 
more efficiently and cost effectively implemented 
using packet switching rather than circuit 
switching. This result appears to be valid over a 
broad range of assumptions and traffic loads- 
...(but) because of the overhead requirements of 
packet switching, long messages are best handled 
in circuit switched networks.” 

Grubb and Cotton (Reference 4c) have ana- 
lyzed effective data transfer rates. As an exam- 
ple, the ARPA Net has an internode’ signalling 
rate of 50 kbps. But due to internode control 
processes (checking packets, acknowledging, re- 
transmission, etc.), the effective internode trans- 
fer rate is about 40 kbps. If one is interested in 
transferring large volumes of data (bulk or file 
transfer) over the ARPA Net, the effective end-to- 
end transfer rate will be much less than 40 kbps, 
say the authors. Due to several end-to-end proto- 
cols that are needed, plus the load on the host 
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computer, the effective transfer rate will be 
somewhere between 4 kbps and 10 kbps. 

While these figures apply to the ARPA Net, 
somewhat similar figures probably apply to other 
types of networks such as circuit switched public 
data networks and private networks. Further, 
the figures are important not just for the transfer 
of large files but also for the down loading of 
programs in some distributed systems. ‘Transmit- 
ting not-large programs to outlying terminals 
might require up to several minutes each, annoy- 
ing if it must be done often. 

The data communications analyses that we 
have studied convey the following message to us. 
Packet switching compares very favorably with 
circuit switching, particularly when a good por- 
tion of the traffic is interactive. The international 
X.25 standard packet protocol provides the begin- 
nings for both domestic and international stan- 
dard packet communication. Yes, the switching 
times in packet networks impose a non-trivial 
overhead. But packet networks compare favor- 
ably with circuit switched networks over a wide 
range of traffic loads. 

We think the upshot can be stated bluntly: 
packet switched networks are where the action 
is. They have just too many good features not to 
be seriously considered by organizations that use 
data communication services. In addition, the ar- 
rival of public packet networks has brought this 
technology within reach of many users. 

In short, you ought to be looking seriously at 
the use of packet switched data communications. 


Types of service and protocols 


By ‘types of service,’) we mean the variety of 
ways that users will want to use the network. 
And by ‘types of protocols,’ we mean the levels 
of procedures that will be needed for supporting 
the types of service. 


Types of service 


Even in those organizations that have imposed 
rather strict company standards on the computer 
types and terminal types that will be used, inter- 
est iS growing in new types of both of these. 
There is a wide range of terminal types now on 
the market, and the capabilities of mini and mi- 
cro computers are becoming impressive. Let us 
briefly list the types of terminals, processors, and 


data transfers that networks will surely have to 
handle. 


Types of terminals. Intelligent terminals provide 
full local programming capability and, very pos- 
sibly, mass storage for files. Quasi intelligent ter- 
minals provide little or no local programming ca- 
pability, but do perform formatting and editing 
functions. The programs for these functions must 
be developed elsewhere and may be ‘down 
loaded’ to these terminals. Non intelligent terminals 
are the equivalent of teleprinter terminals, with 
no formatting, editing, nor (generally) error de- 
tection capabilities. ‘Terminal types also include 
keyboard and display terminals, batch terminals, 
or combinations of these. 

Users will want to be able to attach all of 
these types of terminals to their networks. 


Types of processors. Even where organizations 
have decided to centralize ‘all’ data processing, 
the pressures for some forms of distributed 
processing are growing. Mini and micro comput- 
ers will be showing up in more and more places 
in organizations. And most of these eventually 
will want to have data communications capabili- 
ties. 

A true distributed system will involve a hier- 
archy of processors, or a network of essentially 
equal level processors, or a combination of both. 
The hierarchy structure will usually consist of a 
main CPU and associated front-end processor, 
two or more regional processors at the second 
level, local site processors or controllers at the 
third level, and terminals at the fourth level. The 
network structure probably will consist of a set 
of co-operating processors that can call on each 
other’s services in the performance of their tasks. 
Either structure might also include personal 
work stations that use rather powerful micro 
computers, as we discussed last month. 

Again, many users will want to be able to in- 
terconnect processors in such a manner. 


Types of data transfer. As we have indicated 
earlier, users will want the following data trans- 
fer capabilities: bulk (or file) transfer in which 
hundreds or thousands (or more) of records are 
to be transferred; batch transfer in which tens to 
hundreds of records are to be transmitted; trans- 
action transfer in which a single transaction is 
transferred very promptly and for which a 
prompt response may be required; and interactive 
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transfer which may involve query and response, 
data entry and editing response, text input and 
editing response, and computer message systems. 
Most users will have need for these types of data 
transfer. 

These, then, are the major types of service that 
users in general will demand, we believe. Any 
given organization might try to restrict the vari- 
ety of types actually used. But in a general pop- 
ulation of users, all of these types will be desired. 

Thus, procedures will be needed for handling 
all of these types of service. 


Types of protocols 


To indicate how this subject of protocols for 
supporting the various types of service might be 
approached, we will single out the work of the 
Study Group on Distributed Systems, of the 
ANSI (American National Standards Institute) 
SPARC committee. The study group is chaired by 
Charles W. Bachman, widely known for his pi- 
oneering work on data base management tech- 
nology. 

This study group has postulated the following 
six levels of protocols: 

Level 1, the physical control level. This level of 
protocol adapts the input data stream to the spe- 
cifics of the transmission media on the input end 
and converts back at the output end. 

Level 2, the link control level. ‘This is the point to 
point, or intermediate node to intermediate node 
level of control. It checks to see that individual 
packets are received correctly at each intermedi- 
ate node point. Examples of this level of protocol 
include the data link protocol used in X.25 
(HDLC) and IBM’s SDLC. 

Level 3, the transport (or network) control level. 
This control level provides end node to end node 
procedures. It assures that all of the packets that 
make up a block of data have been received and 
in the right sequence, and then acknowledges to 
the transmitting end node that the block has 
been received. The X.25 protocol is an example of 
this level of procedure. However, it does not pro- 
vide end-to-end assurance and does not demulti- 
plex several messages which may be sharing the 
virtual call. 

Level 4, the message (or session) control. ‘This 
level of protocol is concerned with user process to 
user process control. While Level 3 deals with 
the end point nodes of the data communications 
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network, Level 4 deals with the end point user 
sites. Level 4 thus must acknowledge that the 
complete messages have been received at the des- 
tination user sites. 


Level 5, the presentation control. This is the level 
of protocol that adapts the particular hardware 
and software being used to the standards of the 
network. While data may be transmitted on the 
network under a synchronous discipline and at a 
speed of, say, 56 kbps, the Level 5 protocol 
would have to adapt it to, say, a character at a 
time (asynchronous) operation of 300 bps for 
running a typewriter-like terminal. 


Level 6, user control. Vhis level of protocol is 
designed to permit processes in two user work 
stations to exchange data and thus to cooperate 
in the solution of some problem. This level of 
protocol will often be user-specific. ‘There will 
also be some standard protocols developed within 
certain industries, such as banking and airlines. 


Two basic concepts. The study group has 
identified two concepts that appear over and over 
again in network protocols. 


Fragmentation and re-assembly concept. ‘This con- 
cept occurs at the interfaces between levels two, 
three, and four. Briefly, each of these levels has 
its own data transfer ‘unit’; the unit for level 4, 
for instance, might be a ‘record,’ while the unit 
for level 3 might be a ‘packet.’ So level 4 must 
fragment records into packets, before passing 
them on to level 3 for transmission. At the re- 
ceiving end, level 4 must re-assemble the packets 
into records. The same concept applies between 
levels 2 and 3. 


Multiplexing concept. Again, this concept can 
occur at the interface between levels two, three, 
and four. To illustrate, a point-to-point link at 
level 2 may be used by numerous virtual calls. In 
turn, a single virtual call may support a number 
of sessions, when their end points are the same 
pair of nodes. So the multiplexing for level 2 
may use a series of queues, with one data trans- 
fer unit being drawn from each queue in se- 
quence. However, there would be no reserved or 
empty slots; if a queue is empty, the system just 
goes to the next queue. The data transfer units 
are labelled, of course, so that they can be prop- 
erly de-multiplexed at the receiving end and pre- 
pared for re-assembly. 
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Notice that this concept can provide the prior- 
ity function. Bulk, batch, transaction, and inter- 
active sessions would provide different data 
streams, flowing into different queues. Bulk 
queues would normally be ‘full’ while interactive 
queues often would be ‘empty.’ When an inter- 
active message arrived and was fragmented, its 
first fragment would be transmitted within the 
next commutator cycle. One fragment would be 
transmitted each cycle. 

Let us see how this work of the study group 
fits into international standards work. 


The push for international 
standards 


Actually, we have been told, the big push for 
standards for distributed system networks has 
come mainly from the Europeans. The need to 
interface the various national public data net- 
works is urgent in Europe. And the U.S. has 
been accused of ‘dragging its feet.’ 

The key agency for international standards is 
the [SO—the International Standards Organiza- 
tion. The British Standards Institute urged ISO 
to set up a special sub-committee for distributed 
system network standards, in order to move this 
subject ahead rapidly. Normally, it takes six to 
ten years to get standards developed and adopted, 
and BSI felt that this amount of time could not 
be tolerated for these particular standards. Nor 
does it have to take that long; the X.25 standard 
was developed in three years, we understand. In 
order to co-operate with this effort, the U.S. 
American National Standards Institute set up 
the SPARC Study Group on Distributed Systems 
to work with the new ISO sub-committee. 

There are numerous other groups already 
working on specific standards recommendations 
in this general area. These groups include other 
ANSI groups, a group in the Electrical Industries 
Association, other groups within ISO, and a 
group within CCITT. But no overall structure 
exists for tying these efforts into a cohesive 
whole. Hopefully, the ideas proposed by the 
study group will lead toward that structure. 

To illustrate the need for this overall struc- 
ture, consider the X.25 standard. 


Where does X.25 fit? 


As we reported in our July 1976 report, the 
X.25 recommendations were developed under an 
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unusually rapid time schedule in order to be pre- 
sented to a tri-annual plenary session of CCITT 
in September 1976. It was recognized that a 
standard was needed and needed urgently, to al- 
low for the development of public packet net- 
works on an international basis. X.25 was the re- 
sult. 

As indicated earlier, X.25 applies to Levels 2 
and 3 of the six levels described above. That is, 
X.25 incorporates the HDLC data link control 
protocol for Level 2. At Level 3, X.25 provides 
end node to end node virtual call control, with 
responsibility for seeing that all packets of a 
block have been received correctly (at the end 
node) and are in the proper sequence. 

But it is clear from our discussion of the six 
levels proposed by the study group that X.25 does 
not do the whole job. Its responsibility stops with 
the destination node of the network. It does not 
assure delivery of the packets to the user, on an 
end-to-end basis; this will be particularly impor- 
tant when traffic flows internationally over sev- 
eral inter-connected packet networks. Nor does it 
assure that all blocks of a message have been re- 
ceived. Nor does it provide for handling asyn- 
chronous terminals. 

At present, we are not aware of standards 
work going on at Level 4, for packet networks. 
The public packet networks do provide some 
protocols at this level, but on an individual basis. 
Nor do they seem so comprehensive to us as the 
protocols developed by Electricite et Gaz de 
France, described earlier. 

There is some work going on within CCITT 
for some Level 5 protocols. Hovey (Reference 6) 
describes some such work for a packet assembly 
and disassembly facility for non intelligent tele- 
printer and display terminals. X.3 specifies 12 
basic functions for asynchronous operation, X.28 
describes the interface between the terminal and 
the packet assembly and disassembly facility, and 
X.29 provides end to end procedures for data and 
control information. 

What the ANSI SPARC Study Group on Dis- 
tributed Systems is proposing is an overall struc- 
ture for data communications protocols. If that 
structure is accepted by the various standardiza- 
tion bodies involved, it would do two main 
things. It would point out where the gaps in 
standards exist. And it would define the inter- 
faces of the different levels of protocols, so that 
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the different standards groups could work more 
in harmony. 


Conclusions 


For the past several years, we have been dis- 
cussing in these reports the newly emerging pub- 
lic packet networks. Our research for this report 
convinced us that these networks are already via- 
ble solutions for many data communications 
users. 

It seems to us that if your organization (a) al- 
ready uses or expects to use in the next few years 
a variety of terminal types and processor types, 
with a mixture of bulk, batch, transaction, and 
interactive data flows, and (b) has these termi- 
nals and processors spread over a fairly wide ge- 
ographical area, then you ought to be looking 
into public packet networks. This is even more 
the case if your organization is doing interna- 
tional data communications to countries that 
have (or soon will have) public packet networks. 

The day of the public packet network has ar- 


rived. 
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Public packet networks are only one form of support for distributed sys- 
tems. The rapid developments in micro processors, which we discussed last 
month, also give impetus in this same direction. Distributed network ar- 
chitectures, intelligent terminals, generalized application programs—these 
and other developments encourage the dispersion of computing power and 
data storage. But distributed systems also pose challenges, not only to the 
data processing function but also to user management and staff. Next 
month, we will discuss some of those challenges and steps to take to help 
mitigate them. 
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